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Abstract 


Global  operations  in  a  network  centric  environment  require  high-resolution,  richly  populated  force 
management  data,  constructs  and  management  processes  that  extend  across  Service  boundaries. 
This  paper  presents  an  approach  that  is  based  upon  three  pillars.  First,  realistically,  the  only  way 
to  maintain  force  structure  data  is  to  obtain  it  directly  from  the  agencies  responsible  for  building 
and  maintaining  that  data.  This  requires  that  the  people  who  develop  and  maintain  force  structure 
data  in  the  Services  and  for  the  DOD  must  provide  it  in  a  form  conducive  to  computer 
manipulation  for  use  by  a  diverse  population  of  users.  Second,  force  structure  data  must  be 
formally  and  rigorously  specified  and  its  semantics  unambiguously  defined  and  implemented  so 
that  sophisticated  computer  programs  can  economically  exploit  it.  Finally,  a  common  naming 
convention  must  be  accepted  across  the  Services  with  the  capability  of  being  extended  through 
coalition  boundaries.  This  paper  presents  a  set  of  fundamental  constructs  and  a  description  of  how 
they  can  be  manipulated  to  accomplish  the  objectives  of  the  Global  Force  Management  (GFM) 
process. 

1.  The  Global  Force  Management  Process  Data  Strategy 

In  the  summer  of  2003,  the  US  Department  of  Defense  (DOD)  Joint  Staff,  Force  Structure 
Directorate  (J-8)1  and  the  readiness  portion  of  the  Office  of  the  Under-Secretary  of  Defense  for 
Personnel  and  Readiness  (USD(P&R))2  established  a  Community  of  Interest  for  GFM  (GFM-COI) 
to  tackle  the  challenges  imposed  by  the  Net-Centric  Data  Strategy3.  A  major  impetus  for  the 
establishment  of  the  GFM-COI  was  the  development  of  reliable  and  maintainable  data  sources  for 
the  new  Defense  Readiness  Reporting  System  (DRRS).4  Consequently,  the  objectives  of  the 
GFM-COI  and  DRRS  overlap  in  many  areas.  To  accomplish  these  aggressive  goals,  two  sub¬ 
tasks  were  established.  The  first  addresses  the  data  itself.  This  includes  the  identification  of 
major  data  attributes,  their  instantiation,  maintainability,  and  structure.  The  second  sub-task 


1  See:  http://www.dtic. miPjcs/core/i8.html 

2  See:  http://www.dod.mil/prhome/readiness.html 

3  See:  http://www.defenselink.mil/  nii/org/cio/doc/Net-Centric-Data-Strategy-2003-05-092.pdf 

4  See:  http://www.dtic.mil/doctrine/training/29  drrs.ppt 
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focuses  on  ensuring  that  the  data  is  accessible  to  the  enterprise  in  a  net-centric  environment.  This 
includes  web-enabling  data  access  and  developing  basic  analysis  tools.  Both  sub-tasks  are 
currently  being  executed. 

The  GFM  process  strategy  is  based  upon  the  tenet  that  force  structure  forms  a  foundational 
structure  on  which  to  integrate  battle  command  and  associated  information.^  This  is  illustrated  in 
Figure  1.  Ultimately,  information  about  people,  materiel,  targeting,  plans,  communications, 
information  security,  program  analysis  and  budgeting,  and  most  other  entities  are  linked  by  the 
concept  of  force  structure.  By  defining  and  maintaining  a  rigorously  defined  force  structure  tree, 
straightforward  algorithms  can  be  developed  to  traverse  the  tree  to  collect  and  aggregate  diverse 
information  components  that  may  not  be  anticipated  before  operations  commence.  This  enables 
development  of  ad  hoc  programs  that  derive  information  from  well-understood,  often  predefined 
associations,  or  to  discover  relationships  between  seemingly  umelated  entities. 

A  major  objective  of  the  DRRS  is  to  enable  dynamic  planning  and  rapid  readiness  assessment  in  a 
fast  paced,  net-centric  world.  This  requires  the  ability  to  fuse  current  readiness  status  with 
mission  planning  and  analysis  processes  to  detennine  the  capabilities  of  US  units.  To  accomplish 
this  goal,  high  resolution,  accurate,  and  comprehensive  force  structure  information  is  required 


Targeting 


Because  most  data  items 
ultimately  link  to  the  force 
structure  -  it  may  be  used 
as  the  basis  to  integrate 
battle  command  data. 


4 
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Figure  1:  GFM  Process  Strategy  -  Force  Structure  Pulls  Everything  Together 


5  See  Chamberlain,  Default  Operational  Representations  of  Military  Organizations,  Army  Research  Laboratory 
Technical  Report:  ARL-TR-2172;  February  2000;  http://www.arl.army.mil/~wildman/PAPERS/tr2 1 72.html 
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beyond  that  provided  by  the  current  Status  of  Readiness  and  Training  System  (SORTS)  and  its 
derivatives.  To  achieve  this  end  state,  the  GFM-COI  has  commissioned  the  GFM  Enterprise  Data 
Initiative  (EDI)  to  ensure  the  availability  and  sharing  of  force  structure  data  and  processes  across 
the  Services,  including  all  active,  reserve,  and  National  Guard  components,  and  civilian  and 
contractor  personnel. 

The  GFM-EDI  concentrates  on  three  topics.  First,  realistically,  the  only  way  to  maintain  force 
structure  data  is  to  obtain  it  directly  from  the  agencies  responsible  for  building  and  maintaining 
the  data.  This  requires  that  the  people  who  officially  develop  and  maintain  force  structure  data  in 
the  Services  and  for  the  DOD  provide  it  in  a  form  conducive  to  computer  manipulation  for  use  by 
a  diverse  population  of  users.  This  task  is  called  Authoritative  Data  Source  Identification  and 
Authorization.  Second,  force  structure  data  must  be  formally  and  rigorously  specified  and  its 
semantics  unambiguously  defined  and  implemented  to  enable  it  to  be  used  by  sophisticated 
computer  programs.  To  achieve  this,  a  GFM  Force  Structure  Construct  (GFM-FSC)  has  been 
adopted  and  endorsed.  Finally,  a  common  naming  convention  must  be  accepted  among  the  US 
Military  Services  with  the  capability  of  being  extended  across  coalition  boundaries. 

2.  Authoritative  Data  Source  Identification 

The  first  pillar  is  the  most  difficult.  It  requires  the  traditionally  independent,  Service  force 
development  communities  to  collaborate  and  cooperate  with  each  other.6  An  obstacle  familiar 
within  all  the  Services  is  the  historical  division  of  the  process  of  force  structure  development  and 
maintenance  into  two  tiers.  This  has  produced  a  boundary  at  the  lowest  level  of  Unit 
Identification  Code  (UICs)  assignment  within  each  Service.  It  appears  that  this  has  occurred,  in 
part,  because  it  coincides  with  the  lowest  level  of  official  command.7 8  For  example,  in  the  Army 
and  USMC  it  usually  occurs  at  the  Company  echelon,  in  the  Navy  it  is  at  the  Ship  or  Squadron, 
and  in  the  Air  Force  it  is  at  the  Squadron. 

One  meaning  of  the  term  unit  is:  any  military  element  whose  structure  is  prescribed  by  competent 

o 

authority,  such  as  a  table  of  organization  and  equipment;  specifically,  part  of  an  organization. 
This  implies  that  a  unit  is  defined  in  part  by  the  choice  of  echelon  at  which  one  aggregates  entities 
for  the  purpose  of  documenting  manpower  and  equipment.  Historically,  these  echelons  received 
UICs,  as  do  the  organizational  entities  above  them.  Consequently,  there  is  an  arbitrary 
documentation  boundary  that  occurs  at  the  lowest  level  of  UIC  assignment  in  each  Service.9  At 
and  below  this  boundary  force  structure  documents  exist  that  define  the  aggregate  details  about 
manpower  and  equipment.  For  the  Army  and  USMC,  this  is  exemplified  by  the  company  MTOE 
and  TO/TE,  respectively;  for  the  Navy,  it  is  exemplified  by  the  SMD  for  a  ship  or  an  SQMD  for 


6  Per  Title  10  of  the  US  Code,  force  development  is  inherently  an  internal  Service  task  (see  Sections:  3011,  5011, 
and  8011). 

7  Command  (DOD):  1.  The  authority  that  a  commander  in  the  Armed  Forces  lawfully  exercises  over  subordinates 
by  virtue  of  rank  or  assignment.  Command  includes  the  authority  and  responsibility  for  effectively  using  available 
resources  and  for  planning  the  employment  of,  organizing,  directing,  coordinating,  and  controlling  military  forces 
for  the  accomplishment  of  assigned  missions.  It  also  includes  responsibility  for  health,  welfare,  morale,  and 
discipline  of  assigned  personnel.  From:  http://www.dtic.mi1/doctrine/ieFdoddict/data/c/0108Q.html. 

8  Unit  (DoD),  from:  http://www.dtic.mi1/doctrine/ieFdoddicFdata/u/05570.html. 

9  The  meaning  of  arbitrary  as  used  here  is:  based  on  or  determined  by  individual  preference  or  convenience  rather 
than  by  necessity  or  the  intrinsic  nature  of  something;  from  http://www.m-w.com. 
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an  aviation  squadron;  and  for  the  USAF,  it  is  exemplified  by  a  UMD  for  a  squadron.10  These 
documents  contain  the  templates  from  which  real  units  are  instantiated  and  assigned  UICs. 
Conversely,  operational  reporting  systems,  such  as  SORTS,  begin  at  this  level  (with  few 
exceptions)  and  extend  upward.  Therefore,  the  lowest  UIC  echelons  form  a  jagged  boundary, 
below  which  exists  the  manpower  community  (the  lower  tier)  and  above  which  resides  the 
operations  community  (the  upper  tier),  and  each  tier  has  its  own  set  of  authoritative  data  sources. 
This  is  illustrated  in  Figure  2. 
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Figure  2:  Upper  Tier  and  Lower  Tier  Authoritative  Data  Sources 


Authoritative  data  source  identification  in  the  lower  tier  is  further  compounded  by  the  diversity  of 
information  included,  namely,  materiel  and  personnel  authorization  information.  These  items 
describe  the  number  and  type  of  equipment  and  personnel  authorized  for  the  unit.* 1 1  In  some  cases, 
the  lower  tier  force  structure  developers  do  not  “own”  this  data;  instead,  it  must  be  obtained  from 
and  exchanged  with  the  personnel  or  logistics  communities,  thus  confounding  the  authoritative 
source  identification  task. 


10  Definitions:  MTOE  -  Modification  Tables  of  Organization  &  Equipment;  TO  -  Table  of  Organization;  SMD  - 
Ship  Manpower  Document;  SQMD  -  Squadron  Manpower  Document;  UMD  -  Unit  Manpower  Document. 

11  Type  entities  must  not  be  confused  with  actual  equipment  (e.g.,  with  serial  numbers)  or  people  (e.g.,  with  Social 
Security  Numbers). 
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Finally,  in  all  the  Services  there  is  a  common  partition  between  authorization  data  and  status  data. 
The  manpower  and  equipment  documents  of  the  lower  tier  (just  described)  contain  authorization 
documents.  They  describe  what  should  be,  not  what  is.  In  the  lower  tier,  status  data  includes  the 
roster  of  people  and  inventory  of  equipment  present  (or  available)  to  an  organization.  In  the  upper 
tier  it  contains  the  current  task  organization  that  defines  the  actual  structure  of  deployed  or 
operational  units.  Figure  3  illustrates  this  partition.  On  the  left  are  the  data  sources  that  contain 
baseline,  authorization  data.  This  data  can  be  augmented  with  information  about  the  actual  people 
(e.g.,  the  personnel  roster)  and  equipment  (the  property  book)  present  in  the  organization  to 
produce  status  information;  that  is,  the  actual  condition  of  the  personnel  and  equipment. 
Traditionally,  readiness  is  computed  by  a  comparison  of  what  should  be  to  what  is.  However, 
DRRS  seeks  to  expand  the  way  US  military  units  are  evaluated  to  include  the  concept  of 
“usability.”  Simply  stated,  usability  compares  a  unit’s  status  (both  people  and  equipment)  to  the 
capability  to  produce  an  end-state,  rather  than  to  a  baseline  state.  Usability  is  a  different 
calculation  from  readiness,  and  metrics  are  just  now  being  established  to  implement  this 
significant  change. 


When  the  concepts  presented  in  Figure  2  &  Figure  3  are  combined,  one  can  understand  the 
difficulty  in  identifying  authoritative  data  sources  (ADS).  This  is  illustrated  in  Figure  4  where  the 
distinction  between  the  upper  and  lower  tiers  is  combined  with  that  of  authorization  versus  status 
data  to  create  four  quadrants  labeled  I  through  IV.  Each  quadrant  has  its  own  set  of  ADS’s,  often 
with  different  organizations  and  proponents  maintaining  them.  An  objective  of  the  GFM  process 
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Figure  3:  Authorization  Data  Versus  Status  Data 
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Figure  4:  Four  Quadrants  of  Force  Structure  Data  Sources 

is  to  pull  these  disparate  data  sources  together  into  a  seamless  environment  so  that  readiness, 
usability,  and  other  information  can  be  effectively  and  efficiently  collected.  Thus,  the 
identification  of  authoritative  sources  of  force  structure  data  is  a  prerequisite  to  other  tasks  and 
objectives.  The  next  section  includes  a  description  of  how  the  unification  of  these  four  quadrants 
can  be  achieved. 


3.  The  GFM  Force  Structure  Construct 

The  second  and  third  pillars  of  the  GFM-EDI  address  the  configuration  and  composition  of  force 
structure  data.  The  objective  of  the  second  pillar  is  to  provide  a  continuous,  rigorously  defined 
force  structure  tree  that  extends  from  the  top-most  echelon  (e.g.,  DOD),  across  the  UIC  boundary, 
down  to  the  individual  billets.  This  tree  structure  does  not  require  one  to  eliminate  UICs,  but  does 
relegate  them  to  artifacts  that  represent  popular,  but  arbitrary,  historical  aggregation  points  that 
may  eventually  fade  as  their  usefulness  naturally  wanes.  This  objective  is  achieved  via  the  GFM- 
FSC.  The  remainder  of  this  paper  describes  this  construct. 

The  third  pillar  deals  with  data  identification  across  the  enterprise  in  an  unpredictable,  net-centric 
distribution  environment.  A  simple,  general-purpose  scheme  called  Enterprise  Identifiers,  or 

EIDs,  is  proposed.  The  theory  and  implementation  of  EIDs  has  been  documented  in  previous 

12 

CCRP  papers  and  will  not  be  further  described  this  document. 

3. 1  The  GFM  FSC  Strategy 

The  GFM-FSC  strategy  is  based  upon  the  tenet  that  the  concept  of  force  structure  forms  the 
foundation  to  which  nearly  all  battle  command  data  is  ultimately  linked.  In  simple  terms,  force 


12  See:  http://www.dodccrp.org/Activities/Symposia/7thICCRTS/Tracks/pdf/lQ9.PDF. 

http://www.arl. army, miP~wildman/PAPERS/7thc2rt.html,  or  visit:https://ess. arl.army.mil. 


6 


structure  pulls  all  other  data  together.  Therefore,  if  a  rigorous  set  of  principles  and  constructs  can 
be  agreed  upon  across  the  Services  to  define  force  structure,  it  can  be  used  as  an  integrating  theme 
to  pull  together  other  data  domains;  recall  Figure  1.  Further,  common  algorithms  and  tools  can  be 
developed  to  traverse  a  force  structure  graph  that  is  composed  of  entries  from  any  Service. 

The  ultimate  objective  of  the  GFM-FSC  is  to  provide  rigorously  defined,  high-resolution, 
operational  force  structure  data  that  is  conducive  to  machine  manipulation  and  usable  by  a  diverse 
set  of  users.  This  includes  systems  used  for  battle  command,  personnel  and  logistics  management, 
program  analysis  and  budgeting,  information  security,  and  communications,  just  to  name  a  few. 
Consequently,  the  data  must  conform  to  a  set  of  simple  principles  and  be  general  in  nature. 

The  plan  is  to  begin  by  addressing  the  data  in  Quadrants  I  and  II  of  Figure  4.  The  data  from  these 
two  quadrants  is  merged  and  maintained  in  databases  called  Organization  Servers  (org  servers) 
that  are  controlled  by  the  Services.  The  org  servers  contain  default  force  structure  data  that 
extends  down  to  the  billet  level  and  function  as  the  definitive  source  for  authorization  data  at  all 
echelons  of  the  Service.  Clearly,  the  data  in  the  org  servers  must  traverse  the  traditional 
upper/lower  tier  boundary,  and  this  is  accomplished  using  a  continuous  tree  structure  that  is 
described  by  the  GFM-FSC.  Further,  the  data  is  time-based  so  that  the  Services  can  maintain 
multiple  years  of  force  structure  data  in  a  server.  This  is  accomplished  by  including  a  time 
interval  in  every  node  and  link  of  the  graph  that  defines  when  the  entity  is  viable.  The  graph  may 
be  traversed  using  a  specified  time  to  filter  out  those  links  (and  nodes)  whose  time  period  does  not 
include  the  specified  time.  This  allows  mutually  exclusive  sets  of  links  (based  on  time)  that 
define  different  org  trees  at  different  points  in  time  to  coexist  in  a  server.  Once  the  org  servers  are 
developed,  the  systems  that  comprise  the  domains  defined  by  Quadrants  III  &  IV  can  download 
the  default  force  structure  from  the  org  servers  and  associate  their  real  world,  status  data  with  it. 
Thus,  the  default  data  provided  by  the  Service  org  servers  becomes  a  central  foundation  on  which 
the  other  domains  can  associate  their  data,  thereby  integrating  it  into  the  global  picture. 

3.2  GFM-FSC  -  Default  Operational  Organizations 

The  fundamental  product  of  the  GFM  FSC  is  a  rigorously  defined  force  structure  tree.  The  tree 
conforms  to  the  mathematical  definition  of  a  tree  graph  that  contains  a  set  of  nodes  and  links,  each 
with  an  associated  time  period  that  defines  when  the  node  or  link  is  viable.  As  time  progresses,  a 
node  or  link  continues  to  be  viable  if  its  end-time  is  increased  to  keep  pace  with  the  time 
progression.  In  force  structure  vernacular,  the  nodes  are  named  organizations  and  a  set  of  links  is 
named  a  command  structure.  In  this  formalism,  a  set  of  organizations  with  a  command  structure 
is  called  a  unit.  An  organization  is  a  virtual  entity  in  the  sense  that  it  does  not  physically  exist. 
One  cannot  “touch”  an  organization;  it  is  merely  a  mental  grouping  of  real  objects.14  Perhaps  the 
most  basic  function  of  an  organization  is  to  serve  as  an  aggregation  point  for  other  entities,  in  this 
case,  other  organizations,  materiel,  or  personnel.  In  this  regard,  the  default  meaning  of  the  links  of 
a  command  structure  is  aggregation,  and  a  link  may  be  verbally  interpreted  using  the  words  “is- 
composed-of  (e.g.,  Unit  A  is-composed-of  Organizations  B,  C,  and  D).” 


13  Chamberlain,  Sam  (ARL);  Leeds,  Chris  (USAFMSA);  Time-Based  Tree  Graphs  for  Stabilized  Force  Structure 
Representations',  Proceedings  of  the  8th  International  Command  and  Control  Research  and  Technology 
Symposium;  National  Defense  University,  Ft  McNair,  Washington  DC;  17-19  June  2003; 

See:  http://www.dodccrp.org/events/2003/8th  ICCRTS/pdf/086.pdf. 

14  This  is  why  organization  charts  are  structured  in  so  many  different  ways.  They  reflect  diverse  perceptions. 
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One  reason  for  the  GFM-FSC  is  to  provide  a  process  to  produce  a  stable  set  of  organizations  with 
a  default  command  structure  from  which  other  trees  (i.e.,  new  units)  can  be  constructed  by  re¬ 
linking  the  set  of  organizations.  In  other  words,  it  produces  a  set  of  stable  nodes  with  dynamic 
links.  To  accomplish  this,  the  set  of  organizational  nodes  must  include  those  operational 
organizations  required  to  accomplish  the  expected  tasks  and  missions  assigned  to  a  unit.  This  set 
of  organizations  is  called  the  set  of  Default  Operational  Organizations,  or  DOO. 

An  organization  is  created  to  serve  as  an  aggregation  point  for  other  entities;  therefore,  it  may  be 
categorized  based  upon  the  reason  for  its  creation.  To  date,  three  categories  have  been  defined: 

Billet :  created  for  the  purpose  of  employing  a  single  person.  A  billet  may  not  be  composed  of 
other  organizations,  and  therefore,  must  be  a  leaf  (i.e.,  terminal)  node  in  an  org  tree.  An 
association  may  be  created  between  a  person  and  a  billet  to  represent  the  occupation  of  the 
billet  by  the  person. 

Crew,  created  for  the  purpose  of  employing  a  piece  of  materiel  requiring  operation  by  one  or 
more  persons.  Crew  membership  and  associations  with  equipment  may  be  habitual  or  non- 
habitual  (e.g.,  ad  hoc). 

Doctrinal :  created  for  the  purpose  of  employing  doctrine,  tactics,  techniques,  or  procedures. 

At  any  given  time  in  the  org  server,  there  is  a  single  command  structure  that  is  considered  the 
default  for  the  set  of  DOOs.15  The  time  period  of  a  default  is  typically  several  months,  and  it  is 
modified  in  concert  with  force  structure  authorization  updates  (e.g.,  semi-annually  or  annually). 
User  systems,  such  as  battle  command  systems,  use  the  default  force  structure  as  initialization  data 
and  download  it  from  the  org  servers.16  This  is  the  GFM  vision  for  all  the  Services  and  agencies 
oftheDOD. 

The  default  force  structure  includes  the  time-based,  default  organization  tree  that  extends  down  to 
the  billet  level,  the  organization  templates  from  which  the  organization  tree  was  constructed,  and 
the  associated  amounts  of  types  of  equipment  authorized  and  the  qualification  requirements  for  the 
people  who  fill  the  billets.  Therefore,  this  data  reflects  the  state  of  a  unit’s  planned,  or  ideal, 
status  if  all  the  right  people  are  present  with  all  of  their  equipment.  Clearly,  this  ideal  state  is 
rarely  (if  ever)  achieved. 

To  this  “perfect,”  default  force  structure,  a  myriad  of  other  information  may  be  associated.  Real 
people  may  be  associated  with  the  billets  they  fill;  this  provides  the  bond  between  the  operational 
and  personnel  communities.  In  the  traditional  readiness  context,  one  can  easily  compare  the 
qualifications  required  of  the  billets  with  those  of  the  people  occupying  the  billets.  Similarly, 
information  about  real  equipment  can  be  attached  to  the  org  tree  at  the  appropriate  places,  and  this 
too  may  be  compared  with  the  perfect  world  of  authorized  equipment. 


15  The  term  “stationary  data”  is  used  to  describe  data  that  is  not  static,  but  whose  expected  periodicity  is  known  and 
is  long  enough  to  allow  the  data  to  be  treated  as  static;  for  example,  it  may  be  stored  in  a  server  for  downloading. 

16  This  may  be  direct,  or  more  likely,  implemented  using  an  intermediate  server  that  verifies  the  data  and  adds  other, 
locally  maintained  data,  such  as  personnel  and  equipment  initialization  data. 
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Figure  5:  Complete  View  (Top)  and  Task  Organized  View  (Bottom) 


The  major  feature  and  impetus  of  the  default  force  structure  tree  is  the  ability  to  re-link  the  set  of 
DOOs  into  arbitrary  task  organized  units.  It  is  expected  that  many  systems  have  the  default  force 
structure  preloaded  as  initialization  data.  Therefore,  only  the  new  links  have  to  be  exchanged  to 
define  the  new  task  organization.  This  is  illustrated  in  Figure  5  using  two  org  trees,  each 
composed  of  five  DOOs.  The  top  view  shows  both  the  default  command  structures  (with  solid 
black  lines)  for  each  tree  and  a  new,  temporary  link  (a  dashed  red  line)  that  is  viable  between 
times  ti  and  t2.  Notice  that  adding  the  temporary  links  (e.g.,  attachment)  does  not  affect  the 
existence  of  the  default  command  structure  (e.g.,  assignment).17  The  lower  view  is  simplified  to 
show  only  the  active  links  during  the  task-organized  period.  It  also  includes  the  temporary  aliases 
that  accompany  the  task-organization.  A  major  advantage  of  defining  a  set  of  stable  nodes  is  that 
task  organizing  does  not  change  the  identity  of  the  nodes;  it  only  changes  how  they  are  linked. 
Using  the  force  structure  vernacular  presented  earlier,  no  new  organizations  are  created;  they  are 
just  re-linked  via  a  different  command  structure,  thus  creating  a  new  unit  (org  tree).  If  one 
traverses  the  unit’s  command  structure  during  the  period  of  task  organization,  a  different  set  of 
links  is  traversed  that  connect  a  different  set  of  organizations  than  when  the  unit  is  not  task 
organized. 


17  Assign  (DOD,  NATO):  To  place  units  or  personnel  in  an  organization  where  such  placement  is  relatively 
permanent,  and/or  where  such  organization  controls  and  administers  the  units  or  personnel  for  the  primary 
function,  or  greater  portion  of  the  functions,  of  the  unit  or  personnel. 

Attach  (DOD):  The  placement  of  units  or  personnel  in  an  organization  where  such  placement  is  relatively 
temporary.  From:  http://www.dtic.mil/doctrine/iel/doddict/. 
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Because  many  other  entities  are  associated  to  the  set  of  DOOs,  re-linking  them  retains  these  other 
associations.  Therefore,  the  associated  authorization  information,  status  information  about 
personnel  and  equipment,  and  geographic  information  remain  intact  and  can  be  filtered  using  the 
basic  parameter  of  time.  The  number  and  type  of  associations  that  may  be  added  to  the  default 
force  structure  is  limited  only  by  ones  imagination.  The  set  of  DOOs  and  default  command 
structure  maintained  in  the  Service  org  servers  is  intended  to  be  merely  a  starting  point. 

3.3  GFM-FSC  -  Roles 

A  role  is  an  attribute  of  a  link  that  provides  a  description  of  the  function  or  purpose  of  the  link;  in 
other  words,  it  is  a  name  for  a  link.  Roles  are  common  and  may  be  easily  confused  with  DOOs. 
Figure  6  illustrates  a  familiar  example  of  roles  in  a  Marine  Expeditionary  Unit  (MEU).  The  top 
structure  shows  a  misrepresented  view  where  the  Command  Element  (CE),  Ground  Combat 
Element  (GCE),  Air  Combat  Element  (ACE),  and  MEU  Service  Support  Group  (MSSG)  are 
depicted  as  DOOs.  In  reality,  these  are  not  real  organizations,  but  functions  an  organization 
performs  in  an  MEU.  The  correct  representation  is  depicted  in  the  bottom  view.  In  this  case, 
Battalion  Landing  Team  (BLT)  1/6  performs  the  role  of  GCE. 

Roles  are  an  integral  part  of  aviation  unit  representations,  and  in  particular,  are  required  to 
correctly  characterize  crews.  As  defined  earlier,  the  reason  for  crew  organizations  is  to  provide 
aggregation  points  for  equipment  that  requires  operation  by  one  or  more  persons.  Crew 
membership  may  be  habitual  or  non-habitual.  In  the  habitual  case,  membership  is  defined  by  a 
fixed  set  of  organizations.  For  example,  in  an  Army  armor  unit,  the  tank  crews  are  composed  of 
specific  billets.  This  represents  the  practice  of  the  same  team  of  soldiers  always  working  together. 


18  The  equipment  also  provides  transportation  for  the  crew.  But  this  is  not  part  of  the  current  definition.  It  would 
not  be  technically  wrong  to  consider  an  infantry  machine  gun  team  a  crew  rather  than  a  doctrinal  organization. 
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Similarly,  the  association  between  a  crew  and  its  equipment,  called  alignment,  may  be  habitual  or 
non-habitual.  Army  tank  crews  also  have  habitual  alignment  with  a  particular  vehicle,  so  the  same 
soldiers  work  together  on  the  same  vehicle.  However,  this  is  clearly  a  special  case. 

Roles  are  key  to  describing  non-habitual  relationships,  both  default  and  actual.  They  allow  one  to 
create  a  link  from  a  parent  DOO  without  specifying  the  child  and  to  reserve  a  set  of  links  to  sub¬ 
units  for  pre-define  purposes.  Figure  7  illustrates  the  use  of  roles  to  describe  a  default  USAF 
AWACS  crew.19  In  this  case,  the  roles  are  used  to  describe  the  potential  composition  of  the  crew. 
Many  of  the  links  have  labels  that  describe  the  purpose  of  the  organizations,  indicated  with  dashed 
boxes,  to  be  attached  to  the  various  crew  teams  (doctrinal  organizations).  When  a  mission 
package  is  created,  billets  from  the  squadron’s  flights  are  inserted  into  the  crew  structure  via  these 
roles  (i.e.,  they  replace  the  dashed  line  placeholders).  Similarly,  a  link  is  created  to  associate  an 
airframe  (materiel)  with  the  crew,  as  indicated  by  the  dashed  (red)  arrow  between  the  aircraft 
silhouette  and  the  crew  organization.  Therefore,  one  can  traverse  the  org  tree,  beginning  with  the 
crew  node,  for  a  specified  time  to  produce  the  crew  for  that  instance  in  time.  Because  an  airframe 
is  associated  with  the  crew  organization,  and  people  are  associated  with  the  billets,  one  can  easily 
derive  a  list  of  crewmembers  names  onboard  the  aircraft  by  traversing  the  org  tree  and  collecting 
the  desired  associated  data.  The  difference  is  merely  in  the  representation  inside  the  computer. 
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Figure  7:  A  Default  USAF  E-3  AWACS  Crew  Utilizing  Roles 


19  AWACS:  Airborne  Early  Warning  &  Control  System. 

20  Technically,  a  new  link  is  created  for  the  role  with  a  time  interval  commensurate  with  the  duration  of  the  mission. 
These  links  can  be  retained  to  provide  a  historical  record  of  the  crew  composition. 
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Using  the  GFM-FSC,  an  org  tree  is  used  as  the  integrating  and  mediating  structure  rather  than 
directly  associating  people  with  equipment. 

This  example  illustrates  that  default  force  structure  can  be  defined  using  DOOs  or  roles  (i.e., 
either  nodes  or  links),  and  these  org  trees  can  represent  default  administrative  or  operational 
structures.  Therefore,  even  though  the  administrative  and  operational  structures  may  be  very 
different,  for  example,  in  the  UASF  AWACs  case,  this  does  not  cause  a  representation  problem. 
Figure  8  illustrates  a  default  administrative  structure  for  a  USAF  AWACS  squadron  that  includes 
crew  organizations  as  depicted  in  Figure  7.  This  example  shows  one  of  many  alternatives  for 
adding  the  crew  organizations  to  the  force  structure  (typically,  one  per  prescribed  authorized  or 
present  airframe).  In  this  case,  the  crews  are  added  to  an  operations  squadron,  but  they  could  be 
added  anywhere  within  the  wing  structure.  The  five  Flights,  labeled  A  through  E,  contain  the  300 
plus  authorized  billets  that  are  used  to  deploy  crews  (i.e.,  “plugged-in”  to  the  roles).  There  may  be 

97 

additional  doctrinal  organizations  within  this  structure,  but  they  are  not  included  in  the  UMD. 
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Figure  8:  Administrative  Structure  with  Crews  Added 


3.4  Example 

Figure  9  illustrates  the  application  of  this  representation  for  building  a  strike  package.  This 
example  uses  a  template  (i.e.,  a  TO)  for  a  MARINE  FIGHTER/ATTACK  SQUADRON  (ALL-WEATHER) 
VMFA(AW)  that  includes  F/A-18D  fighter  aircraft.  The  template  must  be  converted  into  a  default 
force  structure  for  a  real  unit,  in  this  case,  VMFA(AW)-224;  this  requires  three  modifications. 


21  The  resolution  of  the  org  tree  is  limited  to  that  provided  by  the  USAF  UMD;  hence,  the  positions  with  multipliers. 

22  An  excellent  example  of  both  administrative  and  operational  command  structures  existing  in  the  same  document 
are  USN  Ship  Manpower  Documents  (SMD)  that  include  the  DOOs  in  an  administrative  structure  and  use  roles  to 
define  the  battle  bill  that  is  an  operational  structure.  For  a  pictorial  example,  see  ARL  Report:  ARL-TR-2172, 
http://www.arl.armv.mil/~wildman/PAPERS/tr2172.html ,  pp  44,  45. 
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Figure  9:  Creating  a  Strike  Package  Using  DOOs  and  Roles 

First,  multipliers  must  be  expanded  to  change  positions  into  billets.  For  example,  most  of  the 
aviators  are  located  in  the  “S-3  Section”  where  the  template  indicates  that  8  naval  aviators  are 
authorized  via  a  position  named  “pilot”  with  the  rank  of  CAPT,  the  primary  Military  Occupation 
Specialty  (MOS)  of  7523  (Pilot  VMFA  F/A-18  Qualified)  and  the  skill  designator  7527  (F/A-18D 
Qualified).  This  position  data  must  be  expanded  into  eight  separate  billets  to  which  people  can  be 
assigned.  In  Figure  9,  under  the  S-3  Section,  15  positions  with  multipliers  have  been  expanded 
into  41  billets  (shown).  Second,  a  crew  organization  is  created  for  each  authorized  aircraft,  in  this 
case,  12  crews.  Each  crew  has  two  roles  attached,  one  named  Pilot  and  one  named  Weapon 
Systems  Officer  (WSO).  Finally,  doctrinal  organizations  are  created  to  reflect  common  tactics, 
techniques  and  procedures.  Aircraft  are  normally  deployed  in  pairs  or  larger  groups.  A  pair  is 
called  a  Section,  so  a  Section  is  created  for  every  two  crews.  Finally,  a  Division  is  four  aircraft 
and  is  often  deployed  as  two  sections,  so  a  division  is  created  for  each  pair  of  sections.  This  set  of 
additional  organizations  converts  the  USMC  TO  template  into  a  default  force  structure  composed 
of  the  DOOs  normally  employed  to  conduct  flight  operations. 


To  create  a  strike  package,  the  default  force  structure  can  be  rearranged  and  augmented  to 
represent  this  structure.  Using  the  principle  of  stable  nodes  and  dynamic  links,  a  subset  of  DOOs 
from  the  default  force  structure  are  recombined  using  a  new  set  of  links.  All  links  include  a  time 


23  In  personnel  vernacular,  a  position  provides  a  description  of  a  job  and  may  have  multipliers  associate  with  it;  for 
example,  “authorized  8  riflemen.”  A  billet  is  a  specific  job  that  may  be  filled  by  a  person;  for  example:  the 
preceding  position  description  can  be  expanded  into  eight  billets:  “Rifleman-1”  through  “Rifleman-8.” 
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interval  that  designates  them  as  viable  during  the  life  of  the  strike  package,  in  this  case,  between 
times  ti  and  to.  This  example  builds  a  four  aircraft  strike  package.  First,  a  foundation  is  created 
by  selecting  three  doctrinal  organizations  (i.e.,  Div-1,  Sect-2,  and  Sect-3)  to  be  connected  together 
via  two  new  links.  For  the  designated  time  period,  the  doctrinal  DOOs  are  given  the  aliases  of 
“Hammer  41,”  “Sect-1,”  and  “Sect-2,”  respectively.  Next,  four  crew  organizations  are  selected 
and  placed  under  the  sections  using  four  new  links,  also  viable  between  times  ti  and  t2,  and  are 
given  the  aliases  Crew  1  through  4.  Billets  are  “plugged-in”  to  the  roles  for  each  crew  to 
designate  the  members  of  the  package.  Because  people  are  associated  with  the  selected  billets, 
this  inherently  assigns  people  to  the  crews.  Next,  airframes  are  chosen  and  aligned  with  crews. 
This  ultimately  associates  people  with  aircraft.  The  essential  difference  is  that,  perhaps  unknown 
to  the  user,  the  association  between  the  aircrew  and  an  aircraft  is  implemented  via  a  small  org  tree 
using  the  GFM-FSC.  Finally,  mission  command  may  be  defined  via  another  set  of  links  called 
“is-led-by”  links.24 

Combined  together,  one  can  now  use  the  small  unit  (an  org-tree)  defined  by  the  organization 
nicknamed  “Hammer  41”  as  an  integration  point  for  a  wide  variety  of  data.  For  example,  the  four 
aircraft  can  be  tracked  as  individual  aircraft,  two  sections,  or  a  division.  Similarly,  missions  and 
targets  can  be  linked  to  any  or  all  of  the  seven  DOOs  employed  in  this  strike  package.  Notice  that 
the  identity  of  the  DOOs  does  not  change  from  the  default.  If  one  did  a  search  of  all  the  links  that 
connect  to  these  DOOs,  there  may  be  many  results.  However,  when  filtered  using  the  parameter 
of  time,  the  sets  of  operational  links  should  be  mutually  exclusive,  thus  providing  a  historical 
record  of  how  the  DOOs  were  employed.  The  stable  nodes  provide  the  persistence  required  to 
continuously  track  military  operations,  while  the  time-tagged  dynamic  links  provide  complete 
flexibility  to  create  any  task  organization  that  complies  with  the  basic  semantics  of  the  GFM-FSC. 

3. 5  Data  Modeling  and  Models. 

To  effectively  implement  an  organization  server,  a  formally  represented,  unambiguous  data  model 
must  be  defined.  The  GFM-COI  will  select  a  data  model  in  the  near  future.  Fortunately,  several 
models  exist  that  include  a  majority  of  the  data  entities  required  by  an  org  server.  The  two  models 
receiving  special  scrutiny  are  the  Command  &  Control  Information  Exchange  Data  Model,  or 
C2IEDM,  and  the  Core  Architecture  Data  Model,  or  CADM.25  Both  of  these  models  evolved 
from  the  Generic  Hub  (GH)  series  of  models  developed  in  the  Army  Tactical  Command  &  Control 
Information  System,  or  ATCCIS  program.  The  C2IEDM  is  also  known  as  the  GH  Version  6,  or 
GH-6.  A  small  subset  of  entities  from  these  models  can  provide  the  minimum  set  of  entities  to 
implement  an  org  server.  Further,  the  subsets  of  entities  (and  their  attributes)  from  the  two  models 
are  almost  identical. 

The  GH  series  of  models  incorporate  five  basic  battlefield  domains:  organization,  materiel, 
person,  feature,  and  facility.  Each  domain  includes  both  instance  data  (i.e.,  real  objects)  and  class 


24  The  use  of  an  “is-led-by”  link  between  an  internal  nodes  of  an  org  tree  and  a  billet  is  described  in  the  reference 
provided  in  footnote  5,  page  2. 

25  C2IEDM,  see  http://www.mip-site.org; 

CADM,  see:  http://www.c3i.osd.mil/org/cio/i3/AWG  Digital  Library/index.htm 

26  ATCCIS,  see:  http://www.mip-site.org/ATCCIS/ATCCIS  Home.htm. 
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data  (i.e.,  descriptive  type  objects)  that  have  the  suffix  “-type.”  Therefore,  there  is  a  set  of 
entities  called  organization- type,  materiel-type,  person- type,  etc.,  that  provide  general  descriptions 
of  their  real  counterparts.  It  is  common  for  many  instances  to  share  the  same  type  definition.  For 
example,  in  the  materiel  domain,  for  a  particular  type  of  materiel  there  are  often  many  real  objects 
(materiel)  with  serial  numbers  of  that  type.  Every  real  materiel  entity  references  a  materiel-type 
entity  that  contains  the  general  description  of  that  real  object;  this  might  include  its  category  as 
defined  in  the  Federal  Supply  Catalog  and  include  a  National  Stock  Number  (i.e.,  NSN).  An 
analogous  condition  occurs  with  all  the  basic  battlefield  domains. 

Initially,  the  org  servers  will  include  data  only  about  three  of  these  domains,  organization, 
materiel,  and  the  person,  as  is  illustrated  in  Figure  10.  This  over-simplified  illustration  uses  a 
graph  of  nodes  and  links  to  depict  the  major  entities  used  in  a  GH-based  model.  The  nodes 
represent  the  basic  battlefield  entities  and  the  links  represent  associations  between  them.  When 
actually  implemented,  both  the  nodes  and  links  are  maintained  within  tables  or  objects. 

An  org  server  will  contain  authorization  data  (i.e.,  the  ideal  case)  and  not  information  about  real 
object,  such  as  people  (i.e.,  person)  or  equipment  (i.e.,  materiel).  This  is  depicted  in  Figure  10  by 
the  exaggerated  boundary  isolating  the  right-most  column  of  nodes  (included  for  clarity).  Entities 
to  the  left  of  the  boundary  are  included  in  an  org  server.  Instead  of  real  people  and  equipment,  an 
org  server  includes  information  about  the  quantities  of  authorized  types  of  equipment  (materiel- 
type,  or  Mat  Type)  and  the  qualifications  required  (person-type,  or  Pers  Type)  of  the  people  who 
occupy  billets.  Examples  of  these  entities  reside  in  the  left-most  column  of  the  figure. 


Figure  10:  Basic  Entities  in  an  Org  Server 


27  The  models  use  the  super  classes  object-item  for  instances,  and  object-type  for  classes. 
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The  foundation  of  the  server  is  the  organization  domain,  and  both  organization  and  organization- 
type  entities  are  included  as  trees  in  the  center  two  columns  of  the  figure.  Recall  that  OrgType 
entities  are  used  to  represent  the  organizational  templates  from  which  real  organizations  are 
established.  Routinely,  many  organizations  are  established  from  a  common  template.  A  key 
feature  of  the  “type”  entities  is  the  presence  of  multipliers  in  the  associations  between  them. 
These  multipliers  are  not  present  in  the  instances. 

Figure  10  presents  an  over  simplified  example  of  a  fictitious  “F/A-99  Crew.”  The  Org  Type  tree 
describes  a  generic  crew  template  for  a  variant  that  contains  two  pilot  positions  as  indicated  by  the 
multiplier  in  the  default  link  between  the  two  Org  Type  nodes.  Verbally,  one  would  state:  “A 
default  F/A-99  Crew  (Variant  2)  is-composed-of  two  Pilots.”  Further,  to  occupy  a  pilot  position, 
one  is  required  to  hold  the  rank  of  Captain  (Capt),  and  have  the  primary  MOS  of  X  and  an 
additional  skill  designator  of  Y,  as  is  defined  within  the  associated  Pers  Type  entity  that  is  linked 
to  the  Pilot  Org  Type  entity  as  depicted  by  the  (red)  solid  arrow  between  them.  It  may  appear 
unnecessary  to  have  a  multiplier  in  this  link,  but  in  the  general  case  a  multiplier  may  be  any  value. 
The  multiplier  of  “1”  is  an  artifact  of  extending  the  FSC  down  to  the  billet  level.  Similarly,  a 
default  F/A-99  Crew  (Variant  2)  is  authorized  one  F/A-99D  aircraft  (as  depicted  by  the  (red)  solid 
arrow). 

The  most  distinguishing  feature  of  an  org  server,  and  the  foundation  of  the  GFM-FSC,  is  the  org 
tree.  Traditionally,  authorization  documents  have  been  templates  from  which  real  organizations 
are  established  and,  in  this  example,  are  represented  by  the  “-type”  nodes  and  links  in  the  left  two 
columns.  Often,  real  units  were  defined  by  adding  a  list  of  UICs  to  an  authorization  document  to 
identify  the  real  units  that  are  to  use  the  template.  Thus,  the  UIC  boundary  was  reinforced 
between  the  upper  and  lower  tiers  via  the  use  of  authorization  documents.  Org  servers  change  this 
by  adding  a  new  structure  composed  of  DOOs  and  a  default  command  structure  expanded  from 
the  org  template.  This  is  the  default  org  tree.  Every  org  (node)  must  reference  the  Org  Type 
(node)  from  which  it  is  established.  This  is  depicted  in  the  figure  by  the  dashed  line  between  the 
org  and  Org  Type  nodes.  This  link  is  often  referred  to  as  an  “is-a”  link  because  it  can  be  verbally 
stated  as  “Crew  12  is-a  F/A-99  Crew  (Variant  2).”  Using  this  link,  the  “Crew  12”  org  entity 
inherits  all  the  properties  of  the  corresponding  “F/A-99  Crew  (Variant2)”  Org_Type. 

An  org  tree  has  no  multipliers.  Individual  links  to  trackable  nodes  replace  the  links  with 
multipliers  that  are  incorporated  in  Org  Type  trees.  This  allows  people  and  real  equipment  to  be 
associated  with  specific  org  tree  nodes  as  is  depicted  in  Figure  10  by  the  (blue)  dashed  arrows 
representing  the  associations  between  the  org  entities  and  materiel  and  person  entities.  In  this 
example,  the  Pilot  position  with  a  multiplier  of  two  is  expanded  into  two  billets,  one  named  “Pilot 
12”  and  the  other  named  “Co-Pilot  12.”  To  these  billets,  real  people  may  be  assigned.  In  this 
example,  external  to  the  org  server,  Capt  Smith  is  assigned  to  billet  “Pilot  12”  and  Lt  Jones  is 
assigned  to  the  billet  “Co-Pilot  12.”  Note  that  one  can  derive  that  Lt  Jones  is  supposed  to  have  the 
rank  of  Captain  to  be  qualified  to  occupy  the  billet.  These  types  of  anomalies  are  common. 

A  subset  of  entities  exists  within  the  C2IEDM  and  the  CADM  to  handle  the  data  representation 
requirements  for  an  org  server.  Additional  attributes  may  have  to  be  added  to  the  entities,  but  the 


28  Recall  footnote  23,  page  2. 
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data  models  already  include  all  the  entities  (nodes)  and  associations  (links)  required  to  represent 
org  trees,  Org_Type  trees,  Mat_Types,  Pers_Types,  and  their  relationships. 

3. 6  Summary  of  GFM-FSC  Precepts 

An  organization  is  a  virtual  entity.  It  doesn’t  physically  exist.  It  is  simply  a  mental  grouping  of 
real  objects  that  reflects  a  person’s  perception  of  the  structure.  For  this  reason,  it  is  rare  for  two 
people  to  create  semantically  similar  organization  structures.  Therefore,  to  improve  consistency, 
interoperability,  human  assimilation,  and  machine  manipulation,  it  is  beneficial  to  develop  and 
publish  a  set  of  precepts  concerning  the  representation  of  organizational  structures.  The  following 
is  a  basic,  but  not  comprehensive,  set  of  construction  guidelines. 

7Q 

3.6. 1  An  organization  chart  should  be  a  tree  graph,  called  an  org  tree. 

Every  node  must  be  connected  to  a  parent,  except  the  root  node  whose  parent  is  itself, 
with  children  is  called  an  internal  node;  a  node  without  children  is  called  a  leaf  node, 
parameters  must  exist  such  that  for  any  given  time  only  a  single  path  exists  between 
nodes.  Pragmatically,  this  requires  that  every  org  must  have  a  default  parent  identified. 

3.6.2  Terms 

Organization :  a  node  of  an  org  tree. 

Command  Relationship :  a  link  of  an  org  tree  used  to  represent  composition; 

it  is  verbally  interpreted  as  “iscomposedof.” 

Command  structure:  a  set  of  command  relationships  used  to  represent  aggregation. 

Unit:  a  tree  graph  composed  of  a  set  of  organizations  and  a  command  structure. 

Default  Operational  Organizations:  a  complete  set  or  organizations  used  to  perform  the  expected 
tasks  required  of  a  unit. 

Defaidt  Command  Structure:  A  command  structure  depicting  the  organic  composition  of  a  unit’s 
default  operational  organizations. 

Role:  a  named  given  to  a  command  relationship  to  define  or  distinguish  its  purpose.  The 
command  relationship  is  not  required  to  have  a  child  node  (i.e.,  it  may  be  used  as  a  placeholder 
or  template). 

3.6.3  Time 

Every  organization  and  command  relationship  will  include  a  time  interval,  based  upon  real  time, 
to  denote  the  time  period  that  the  entity  is  viable.  This  will  allow  filtering  based  upon  real  time. 
Recommended  attribute  names  to  define  the  interval  are  s_time  (start  time)  and  t_time 
(termination  time).  The  term  effective  time  (or  date)  is  avoided  because  it  already  has  several 
preconceived  meanings. 


A  node 
A  set  of 
any  two 


29  For  a  formal  definition  of  a  tree,  see  http://en.wikipedia.org/wiki/Tree  (graph  theory)#Definitions.  or 
Knuth,  Donald  E.  Fundamental  Algorithms  (Vol  1)  -  The  Art  of  Computer  Programming  (2nd  Ed).] 
Addison- Wesley  Publishing  Company,  1973;  ISBN  0-201-03809-9;  Page  305. 
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3.6.4  Categories  of  Organizations 

An  organization  should  have  a  reason  for  being  entered  into  a  tree.  Currently,  there  are  three 
reasons  for  creating  an  organization:  Billets :  -  for  employing  a  single  person;  Crews  -  for 
employing  a  piece  of  materiel  requiring  operation  by  one  or  more  persons;  and  Doctrinal  -  for 
employing  doctrine,  tactics,  techniques,  or  procedures.  Recall  page  2  for  additional  infonnation. 

3.6.5  Resolution 

Org  trees  will  extend  down  to  the  billet  level  and  include  the  crews  and  doctrinal  organizations 
required  to  perfonn  expected,  routine  operations.  This  applies  to  the  Active  and  Reserve 
components,  civilian,  and  conceivably,  contractor  organizations  or  personnel. 

3.6.6  Crew  Terms  and  Semantics 

A  crew  should  be  created  for  each  asset  (i.e.,  platform)  expected  for  a  unit.  For  example,  every 
ship,  aircraft,  or  drivable  vehicle  should  have  an  associated  crew. 

Assignment:  the  process  of  building  crew  membership. 

Alignment:  the  process  of  creating  associations  between  entities  of  the  materiel  domain 
and  a  crew  (i.e.,  linking  equipment  to  a  crew  organization). 

Crew  assignment  and  alignment  are  independent  processes  and  may  be  habitual  or  non-habitual. 
Non-habitual  assignment  may  be  implemented  using  roles.  This  commonly  occurs  in  aviation 
crews  where  roles  are  used  to  define  the  functions  of  their  transitory  members. 

3.6.7  Mandatory  and  Optional  Associations 

At  a  minimum,  a  default  force  structure  will  be  provided  that  consists  of  a  set  of  default 
operational  organizations  and  a  default  command  structure  that  depicts  the  organic  structure  of  an 
unit.  The  choice  of  optional  associations  within  the  organization  domain  is  limited  only  by  the 
imagination  of  the  developer.  Two  common  sets  of  optional  links  are  a  default  operational 
command  structure  and  “is-led-by”  links. 

The  default  operational  command  structure  depicts  additional  habitual  command  relationships  or 
well-known  alternative  command  structures.  The  only  requirement  is  that  the  command 
relationships  be  clearly  annotated  to  allow  traversal  using  any  additional  set  of  associations  (e.g., 
an  administrative  versus  operational  command  structure). 

Examples  of  these  abound.  US  Navy  Ship  Manpower  Documents  contain  both  an  administrative 
command  structure  (composed  of  Departments,  Divisions,  Work  Centers,  and  billets)  and  the 
Battle  Bill  that  depicts  the  operational  command  structure  during  battle  stations.  The  Battle  Bill 
includes  no  billets,  but  uses  roles  that  specify  the  requirements  for  billets  to  fill  the  role  (from  the 
administrative  command  structure).  Similarly,  Anny  units  have  well-known  habitual 
relationships,  such  as  those  between  the  elements  of  a  direct  support  artillery  battalion  and  its 
supported  maneuver  brigade.  These  associations  can  be  easily  added  to  the  default  force  structure. 
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Another,  more  advanced  association  is  the  ”is-led-by”  association.  A  basic  military  condition  of 
any  crew  or  doctrinal  organization  (i.e.,  an  internal  node)  is  that  someone  is  always  in  charge  of 
that  aggregation  of  organizations  (i.e.,  the  people  and  equipment).  A  useful  requisite  is  to  require 
that  every  active  internal  node  have  a  default  “is-led-by”  association  added  to  identify  the  default 
billet  that  is  nominally  in  charge  of  the  unit  rooted  by  the  internal  node.  If  one  is  not  identifiable, 
then  the  internal  node  should  not  be  added.  The  term  “active”  is  used  because  an  internal  node 
may  incorporate  roles  without  children  nodes  (i.e.,  serve  as  placeholders).  When  the  roles  are 
filled,  the  internal  node  becomes  active  and  an  is-led-by  link  must  be  added.  It  is  pennissible  to 
designate  a  role  as  a  default  is-led-by  link  (e.g.,  “the  pilot  of  a  crew  is  always  the  leader”). 

4.  Summary 

Global  operations  in  a  network  centric  environment  require  high-resolution,  richly  populated  force 
management  data,  constructs  and  management  processes  that  extend  across  Service  boundaries. 
This  paper  presents  an  approach  to  implement  a  set  of  organization  servers  across  the  DOD  to 
allow  the  sharing  of  detailed,  accurate,  force  structure  data  that  extends  down  to  the  billet  level. 

Realistically,  the  only  way  to  maintain  this  level  of  force  structure  data  is  to  obtain  it  directly  from 
the  agencies  responsible  for  building  and  maintaining  that  data.  This  requires  that  the  people  who 
develop  and  maintain  force  structure  data  in  the  Services  and  for  the  DOD  must  provide  it  in  a 
form  conducive  to  computer  manipulation  for  use  by  a  diverse  population  of  users.  The  list  of 
systems  that  require  this  data  is  large  and  includes  the  areas  of  battle  command,  logistics, 
personnel,  readiness,  communication,  infonnation  security,  and  planning  and  budgeting. 
Therefore,  the  servers  and  the  data  they  contain  must  be  designed  so  that  a  diverse  set  of 
developers  can  automatically  obtain  and  manipulate  the  data  to  transfonn  it  into  the  products 
require  to  conduct  business  in  their  environments.  This  requires  a  formal  and  rigorous  approach 
be  used  to  define  and  maintain  the  information. 

The  assertion  is  presented  that  the  central  theme  through  which  all  battle  command  processes 
converge  is  the  fundamental  concept  of  force  structure ;  consequently,  it  can  be  used  as  a 
foundation,  or  bridge,  to  integrate  other  battle  command  concepts  and  data.  To  help  achieve  this, 
a  set  of  basic  precepts  was  presented  that  define  how  to  represent  force  structure  data  in  a  fonn 
that  is  Service  independent.  This  extends  beyond  a  data-modeling  task.  Organizations  are  virtual 
entities  that  do  not  physically  exist.  They  are  simply  mental  groupings  of  real  objects  that  reflect 
a  person’s  perception  of  the  structure.  Given  a  particular  data  model,  that  data  can  be  instantiated 
from  many  different  perspectives.  The  precepts  provide  a  small  amount  of  discipline  to  simplify 
this  task  to  increase  the  ability  to  understand  and  exchange  the  data,  preferably  by  machines.  Two 
primary  precepts  are:  one,  to  formally  represent  force  structure  as  sets  of  organization  trees,  and 
two,  to  include  doctrinal,  crew,  and  billet  entities  as  organizations  in  those  trees.  This  allows 
information  about  people  and  equipment  (i.e.,  the  primary  resources  of  the  DOD)  to  be  tightly  and 
unambiguously  coupled  with  the  operational  domain.  Further,  this  provides  a  consistent,  unified 
structure  that  extends  down,  beyond  the  current  UIC  boundary,  to  the  billet  level  to  which  any 
information  may  be  associated. 
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It  is  the  actual  force  structure  data,  not  its  theory  or  a  model,  which  is  required  by  battle  command 
and  other  system  users.  Historically,  in  the  absence  of  data,  those  in  need  create  it  themselves. 
Force  structure  data  is  no  different.  As  a  result,  there  are  many  different  sources  of  force  structure 
data  available  throughout  the  Services,  in  various  forms  and  different  levels  of  detail.  Clearly, 
they  are  not  synchronized  and  require  extensive  effort  to  keep  current.  The  GFM-COI  is 
confronting  this  challenge.  This  includes  an  aggressive  set  of  milestones  to  produce  GFM  data  for 
the  net-centric  environment  that  is  accessible  by  the  combatant  commanders,  across  the  Services, 
and  ideally,  among  coalition  partners. 
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